5 ms·

> For the life of me, I could not figure out why he would not save his changes before pulling stuff down on top of them. He appears to be using git with the sv

by EdiX 15y ago

> For the life of me, I could not figure out why he would not save his changes before pulling stuff down on top of them. He appears to be using git with the svn workflow (svn update; svn commit).

Roboprog 15y ago
OK, thanks for the reminder. Even back when I did use SVN regularly at work, we usually worked on feature branches, and seldom ran into collisions requiring that process. I'd forgotten that SVN will force an updage (merge) before commit in some cases. It had not occurred to me that somebody would internalize that as SOP.
barrkel 15y ago
That's not my svn workflow; it's svn diff to a patch file, svn revert, svn update, then patch from the patch file (and resolve conflicts if necessary with a decent third-party tool), then finally svn commit. I run svn diff multiple times a day. I frequently have many different patches related to different functional areas and bug fixes. Effectively I work with local branches implemented on top of svn. I have a whole suit of scripts that automate this. Seemed like the only workable way to use svn in a disconnected fashion to me.
- masklinn 15y ago
  > Effectively I work with local branches implemented on top of svn. I have a whole suit of scripts that automate this. Seemed like the only workable way to use svn in a disconnected fashion to me. Why don't you just use git-svn or hgsubversion and stop doing that informally? Or at the very list use something like `quilt`, so that your changes are represented as a stack of patches on your svn "upstream"
  - barrkel 15y ago
    I've already discussed it elsewhere on this site earlier, I'm not about to go into it again, sorry.
    - barrkel 15y ago
      Interesting that apologising for not replying in more detail, yet hinting at where to find previous discussion of that detail, is treated with such hostility! I'll simply not reply at all in future, in such cases.

by EdiX 15y ago

> For the life of me, I could not figure out why he would not save his changes before pulling stuff down on top of them. He appears to be using git with the svn workflow (svn update; svn commit).

Roboprog 15y ago

OK, thanks for the reminder. Even back when I did use SVN regularly at work, we usually worked on feature branches, and seldom ran into collisions requiring that process. I'd forgotten that SVN will force an updage (merge) before commit in some cases. It had not occurred to me that somebody would internalize that as SOP.

barrkel 15y ago

That's not my svn workflow; it's svn diff to a patch file, svn revert, svn update, then patch from the patch file (and resolve conflicts if necessary with a decent third-party tool), then finally svn commit. I run svn diff multiple times a day. I frequently have many different patches related to different functional areas and bug fixes. Effectively I work with local branches implemented on top of svn. I have a whole suit of scripts that automate this. Seemed like the only workable way to use svn in a disconnected fashion to me.

masklinn 15y ago
> Effectively I work with local branches implemented on top of svn. I have a whole suit of scripts that automate this. Seemed like the only workable way to use svn in a disconnected fashion to me. Why don't you just use git-svn or hgsubversion and stop doing that informally? Or at the very list use something like `quilt`, so that your changes are represented as a stack of patches on your svn "upstream"
- barrkel 15y ago
  I've already discussed it elsewhere on this site earlier, I'm not about to go into it again, sorry.
  - barrkel 15y ago
    Interesting that apologising for not replying in more detail, yet hinting at where to find previous discussion of that detail, is treated with such hostility! I'll simply not reply at all in future, in such cases.