Jump to content


Adding a new file with same name (and path) as a deleted one

add deleted file deleted at HEAD revision

  • Please log in to reply
9 replies to this topic

#1 mazay

mazay

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 30 October 2018 - 08:03 PM

Hi,

I'm having problem finding a solution for this.

If I delete a file using ClientAPI::Run("delete") of the C++ API and then create a new file with the same name and the same path in the same workspace, when i look into p4v, the file is "Deleted at HEAD revision". This is causing me problem since I cannot mark the file for add. Is there a way I can add the new file, without losing my new changes to it? Something that would cause the HEAD revision to mark the file for add?

Thanks!

#2 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 639 posts

Posted 30 October 2018 - 08:16 PM

Option 1 (one changelist with your change as an "edit"):
p4 revert -k FILE
p4 edit FILE

Option 2 (two changelists representing the "delete" and "add" as separate actions):
move FILE tmp
p4 submit -d "delete"
move tmp FILE
p4 add FILE


#3 mazay

mazay

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 31 October 2018 - 02:31 PM

Using C++ API, Option 1 makes my file "checked out in default changelist" in p4v and I am unable to submit it unless I "move it to another changelist" in p4v. Here is the command that p4v does when i move it : p4 reopen -c default path/to/file. How can I just have a file that is marked for add?

Thanks alot for your time.

#4 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 639 posts

Posted 31 October 2018 - 03:28 PM

Test all of this from the command line before trying to do it in your C++ app, it'll make it a lot easier for you to just run the commands and see how they behave with a lot less typing and compiling.  :)

"Marked" means the same thing as "checked out" (or in normal Perforce terminology "opened").  Why wouldn't you be able to submit it when it's in the default changelist?

Both of these sequences will leave you with a file that is opened.  Option 1 leaves it open for edit, option 2 leaves it open for add.

You can't "add" a file that's already there, which is why you need to submit the delete before you can reopen the file for add (option 2).  If you don't want to submit the delete, open the file for edit instead (option 1).

#5 mazay

mazay

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 01 November 2018 - 02:09 PM

Great thanks!

Now, let's say the "edit" fails, how can I revert the "revert -k".

#6 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 639 posts

Posted 01 November 2018 - 02:58 PM

View Postmazay, on 01 November 2018 - 02:09 PM, said:

Now, let's say the "edit" fails, how can I revert the "revert -k".

...what state are you trying to get the file into?  And why would the "p4 edit" fail?

#7 mazay

mazay

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 01 November 2018 - 03:37 PM

Since this is for an app, the user could experience a problem while doing the edit (getting disconnected, for example). In that case, I don't want to let the file "in between" the two operations. The file as to go back to it's former "marked for delete" state in the depot without actually getting deleted from the local workspace.

#8 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 639 posts

Posted 01 November 2018 - 05:21 PM

That leaves them with an inconsistent workspace, though.  Surely you should just retry the "p4 edit" operation?

It would probably be useful to describe what your app is trying to do overall.  I have a strong hunch you could throw out most of your code and just use "reconcile".

#9 mazay

mazay

    Newbie

  • Members
  • Pip
  • 8 posts

Posted 01 November 2018 - 06:39 PM

Well the app manages audio files. You can create and edit files with it. I'm trying to add support for Perforce. So far, I can do pretty much all the basic commands like add, delete, edit, move, resolve, revert, filelog, diff... Thing is, if someone, using the app, deletes a file and creates a new one with the same name at the same place (without submitting), the app will try to add it to the workspace and the file will get deleted when the user submits. So, I'm trying to prevent that by checking if it's marked for delete on the depot and then do the option1 (revert -k, edit) to make sure the file will be added with the new content in it. Hope that is clear enough :P

Thanks again

#10 Sambwise

Sambwise

    Advanced Member

  • Members
  • PipPipPip
  • 639 posts

Posted 01 November 2018 - 08:37 PM

If you want everything to "just work" at the time you submit, you could skip the add/delete/edit/move operations, just have the user do whatever they want on the local filesystem, and then when it's time to submit do "p4 reconcile" to automatically open everything for the appropriate action.

If you want the user to have more control/visibility into the way their changes are being versioned, I'd be more inclined to surface an error when they try to do something like add a file that they have a pending delete for -- converting it to an edit lets them submit their change, but it does lose the fact that they deleted it (which might actually be important to someone who wants tighter control of their version history).





Also tagged with one or more of these keywords: add, deleted, file, deleted at HEAD revision

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users