# VCS that behave like svn and git ( at the same time ).



## rigoletto@ (Aug 22, 2018)

Hi.

This is just a matter of curiosity, but do exist any source control system that ( can ) work a long lines with something like svn + git?

I mean, lets say I created the "Dæmon Project"! Trunk/Head and its branches would work/behave like a centralized VCS, but it allow me ( authorized people ) to create something like mini internal forks that work/behave like a distributed VCS. So, all the work would be done on those "mini forks" and later,  when everything is _ready_, a big single commit/patch bring it to trunk/head ( while retaining the relevant information about the previous work ).

Thanks!


----------



## Cthulhux (Aug 22, 2018)

It sounds like Darcs (or Pijul, but that's alpha-state yet) is what you need.


----------



## rigoletto@ (Aug 23, 2018)

I will look on those. Thanks!


----------



## vit. (Aug 23, 2018)

There is also git-svn
https://git-scm.com/docs/git-svn
However, I didn't have much experience with it.


----------



## Bobi B. (Aug 23, 2018)

I believe git(1) provides svn(1) integration. Perhaps it will fit your needs.

Edit: I just saw, that vit already made this suggestion. Kudos!


----------



## rigoletto@ (Aug 24, 2018)

vit. said:


> There is also git-svn
> https://git-scm.com/docs/git-svn
> However, I didn't have much experience with it.





Bobi B. said:


> I believe git(1) provides svn(1) integration. Perhaps it will fit your needs.



This is not actually something I need but a curiosity about if there is something 'out there' ( even if primitive ) that can properly substitute this exactly arrangement. In other words, a centralized VCS that allow the "kitchen"  work to be done in "distributed mode".

On the other side the _patch_ approach of Pijul seems interesting to test. I will set it up in a near future.

Thanks!


----------



## rigoletto@ (Oct 25, 2018)

So, just to exemplify:


```
----------------------------------> trunk, master tree | behave like Subversion | true VCS system
   |         |------------------> clone, regular local working copy | behave like Subversion
   |--------------------------> child, git like working copy | server or local created/managed | allow rebase/reset etc. | not a true VCS
```


----------



## kpedersen (Oct 25, 2018)

Git Fusion (from Perforce) is kinda similar. It uses the Perforce server as the backend but Git as a front end.

Also, GitHub (and the GitHub Enterprise server) allow access from svn clients but store it in a git server backend.


----------



## ShelLuser (Oct 25, 2018)

I'm not sure I understand where the SVN part comes from because from my current experiences with Git so far it should be easily doable to set up such an environment using only Git. Unless of course you meant to enforce the *trunk* behavior; iow all changes made to the *trunk* are required to be pushed onto the *trunk* right away.

Still, this is something that Git could do on its own. It wouldn't really be enforced I suppose because it focuses on decentralized storage, but all you'd need is for your developers to be on the same level as you. So: changes to the *trunk* would need to be instantaneously pushed as per your own rules.

I guess the main difference is that Git can easily perform the role of *clone* and *child* at the same time.


----------



## Crivens (Oct 25, 2018)

Have you looked into _fossil_ yet?
You can have a master repro where you push to as trusted user, all others need pull requests. And it comes with wiki and ticket system in the same repo.
I hugely like it. Now if it could handle symlinks... but who can.


----------



## rigoletto@ (Oct 25, 2018)

ShelLuser

The reason I am thinking about something like that is, in short, THIS.

Crivens

I've not aware of fossil. I will try it out. Thanks!


----------



## ShelLuser (Oct 26, 2018)

Rigoletto said:


> ShelLuser
> 
> The reason I am thinking about something like that is, in short, THIS.


<sighs>

Ok, fair warning because I am most definitely biased. Here is proof of that. So it should't come as a surprise that I seriously disagree with that post.

Here's the thing: I get the impression that the posters have never gotten their hands dirty with Git, only a quick glimpse for a brief impression and that is the foundation of their whole argument. Note: _impression_.



> The absense of a progressing version number and lack of a definitive
> timeline, not to mention all the many "unnatural acts" you can do
> to a git repo are sufficient arguments to settle this point.


Uh huh...


```
commit 77291ab54344a58b8574cee30eed6d3059924862 (HEAD -> master, intranet/master, dev)
Author: ShelLuser <ShelLuser@users.noreply.github.com>
Date:   Mon Oct 8 21:41:49 2018 +0200

    Added check for portmaster

commit 851265b482668566a853bb6782d76f65b9adab63
Author: ShelLuser <ShelLuser@users.noreply.github.com>
Date:   Sun Sep 23 07:07:53 2018 +0200

    Bugfix with PKG variable and outdated parameter usage for update script.

commit 1088a5d02e00404e248601f634b0baface67b659
Author: ShelLuser <ShelLuser@users.noreply.github.com>
Date:   Thu Aug 23 15:20:07 2018 +0200

    Changed option 'upfull' into 'full'.
```
Notice the timestamps in this log? How does that not make up for a timeline?

And about those version numbers... True, you don't get to see those in the default way in which Git displays the commit entries, but does that also mean that those aren't there?  I wonder....


```
peter@zefiris:~/updates# git describe 77291ab54344a58b8574cee30eed6d3059924862
beta1-32-g77291ab
peter@zefiris:~/updates# git describe 851265b482668566a853bb6782d76f65b9adab63
beta1-31-g851265b
peter@zefiris:~/updates# git describe 1088a5d02e00404e248601f634b0baface67b659
beta1-30-g1088a5d
```
Wait a second, do I see a decreasing numbering system in there? Could those be version numbers? 

The real question here though, in my opinion of course, is: does the existence of these version numbers actually matter with regards to the way you're using Git? I fail to see the need to have these numbers on display all the time, I'd seriously rather see that which matters most to me by default: who commited, when they commited and the commit description. But fact of the matter though is that version numbers do exist, the only issue here is that Git doesn't display those by default. How did they think Git would keep track otherwise? I'm a little flabbergasted here.

And about those unnatural acts with regards to the repository...  _Only with local access_.

To me this is no different than starting a rant on how FreeBSD isn't secure because if you start it in single user mode then you don't get a password prompt by default (some people actually complained about that). _Yah_, duh. If you have local access to a server then obviously you have full control over it, no matter what.

The same applies to Git. Once you pushed something onto a remote repository then it is out of your control from there on. You cannot "just" undo your changes because that's simply not how it works. Please see git-revert(1) for more information on this. Note how they mention that this reverts _commits_ and not pushes? A push is not a commit. Sure: I could revert locally, mess with my local repository and then push that onto the remote system again. But surely you don't think that will magically make the whole thing disappear? It won't: it will continue to add to the development cycle, leaving all your steps wide open for everyone to see.

The only difference between SVN and Git on this end is that Git makes it easier (more accessible), and then there will always be people who don't look beyond the obvious and simply assume that everything can be tweaked "because". Bullshit. Once you pushed your changes onto a remote repository then the _only_ way to undo that is to have physical access to said repository. And even then it becomes tricky because if you don't know the detailed parameters to use you'll end up with another new commit which clearly details your revert of the commit you tried to undo. It's not as if this is easily done either.

Note that I'm not denying that Git provides much more control over the repository. It's true.

I have a small project running on GitHub and I want to keep the "release revision" as clean as possible. So it only lists major changes but not every small test and trial I did. Therefor I maintain several local branches and when I have done enough work which warrants a new "release commit" I merge my two branches together and... wait, I'll show you differently:






This is the short version of it, in reality I also maintain a _stage_ branch to actually test the whole thing.

Let me explain: this is all local. The master branch is the version of the project I work with myself. If I check the log for the master branch in the status I showcased above I see what you'd come to expect: _added documentation_, _version 2_, _small change_, _fixed bug_, _new feature_, _version 1_. So both my dev and master branches combined. Also noteworthy: the uplink for the master branch is a Git repository on my LAN server, so if I push my work it gets stored there.

Onto the GitHub branch. This branch has a different uplink: GitHub itself. If I push my work while this branch is active it gets stored onto GitHub and as such will become publically available. I don't want to bother others with every small detailed step I made. So yes; when I merge my work from the master I squash it. Meaning that I combine all my commits into one merge in which I fully explain the changes in the description.

I suppose you can call this an "unnatural commit" but fact of the matter is that the end results stay the same. The only difference is that someone doing a `git diff` gets to see all the applied changes in between versions. The only difference is the amount of steps which are in between.

Once again I am biased.

The problem, the way I see it, is that things change and evolve. Also for VCS systems. And sometimes that can become rather complex. If you look at my example above where one (local) repository uses 2 different uplinks for different branches then I hope you can agree that this is a decently complex setup. And that's only scratching the surface: the GitHub branch even contains files (policy, readme, todo list) which aren't even part of the Master branch.

So when I read that post I can't help but wonder if the author truly understood the nature of Git. I have some serious doubts about that. Reading that stuff immediately brought me back to news reports years ago in local (printed) media about how Sun Solaris' UFS filesystem didn't support journaling. Which was utter bullshit; the only thing was that journaling wasn't enabled on UFS by default: you had to turn it on yourself. Yet that didn't stop "professional" journalists from concluding that UFS at its start didn't support journaling <facepalm>

Git is as much of a version control system as Subversion is. The only problem is that some people fail to understand how it really works and what it can (and cannot) do.

(edit): re-reading I'm also wondering if some people actually think that pull requests are only done because people don't want to give others too much control over their repository. Because that would be utter bullshit too. Fact of the matter is that it's much easier to pull something, check the commit then and there and only afterwards decide if you want to keep the changes or not.


----------



## rigoletto@ (Oct 26, 2018)

Everything looks fine until someone use git-reset(1) or git-rebase(1) and change everything. 

It is not about git being a bad tool but about it allowing changes that were not supposed to exist in VCS tool. If you look at description of what I am looking for it is something with a proper VCS design but with the built in git-like facility; however without the possibility of it (git-like) contaminating the "master" thing with all kind of unappropriated changes allowed by its features. So, basically git-svn(1) workflow but in a single integrated tool.

Yeah, you can use git without ever touching on those features, but the problem is they were not supposed to be in there first place.


----------



## rigoletto@ (Oct 27, 2018)




----------



## obsigna (Oct 27, 2018)

In 2013, I wrote a post in the thread "Opinions on version control systems“ on this Forum, at that time I was user rolfheinrich (s. https://forums.freebsd.org/threads/opinions-on-version-control-systems.38745/#post-214985)


„rolfheinrich said:


> I was also a former mostly happy CVS user, and I switched to SVN, mainly because I do all my coding using Xcode on Mac OS X, and CVS support has been abandoned in Xcode 4.x, which got built-in support for SVN and Git.
> 
> Besides this, my requirement list was very similar to yours, and with SVN, I almost immediately felt at home.
> 
> ...



It is interesting how history is keeping on repeating, isn’t it? Now in 2018, it happened again, and Apple decided to abandon Subversion support from Xcode 10, leaving Git as the only integrated VCS option. Now, I got my fingers wet with Git, and I still don’t like it, and YES the UI is a big mess like Ed Maste showed in his presentation. I migrated my first SVN projects to Git, and I documented the process on my BLog (in German language): Xcode 10 kommt ohne Subversion-Integration.

There I wrote about Git: _"Everything is as easy with it like pulling a tooth. Yes, it's easy, but not painless."_ I will work with Git like it were Subversion or even CVS. One central repository (of truth) and all working copies are derived from this. I won’t jump on the distributed VCS train, no way. My words from 2013 on this keep-on being valid for me:

_IMHO, the worst thing was that every member of the development group was coding on his own clone, and from time to time the changes were pulled into the main line OR NOT. I am a physical chemist, and we call that entropy generation, i.e. dissipation of working energy into hot air. So for me the concept of distributed VCS looked nice on the  paper, but in practice it turned into an unmanageable mess._​


----------



## ShelLuser (Oct 27, 2018)

It is not my intention to start an endless debate because I think that would be a little unfair towards the OP. However, one small comment (even somewhat related to the thread IMO):



obsigna said:


> I will work with Git like it were Subversion or even CVS.


And there's your problem right there I think. If you're using a tool as if it were something else then you're going to have a nasty experience. Instead of using Git as something it's not, why not use the tool which better matches your preferred workflow? So why not stick with Subversion or maybe CVS?

I still can't help but get the impression that your experiences boil down to picking the right tool for the right job. I am definitely biased towards Git because it does everything I need in a way which I can even enjoy, but I'm not zealous enough to think that Git is therefor also the universal answer to everything VCS related.

(edit) Just to be sure: I read that support got pulled from XCode. But why should that stop you? And for the record: I can definitely agree about Git integration in IDE's. I got Git support in NetBeans but I think it's plain out horrible. For the simple reason that the IDE already provides a bit of version control (keeps track of code changes) which makes a local Git repository seem like a seriously useless and redundant option. I really don't enjoy Git usage with NetBeans because of that (committing and then pushing instead of simply commiting & I'm done).


----------

