"Remote branches" extension

[venizio krups]

2010/5/17 Rafael Fernández López <ereslibre at kde.org>:
> Hello all,
>
> I have never written to this list, so I introduce myself: I am Rafael
> Fernández López, a KDE contributor, and a DVCS enthusiast. I love
> Mercurial, but I always end up using Git. I recently had an idea on
> how to improve certain work models using Mercurial, and how to catch
> up Git.
>
> = Work model =
>
> I believe my work model is really easy and common, but just in case, I
> explain it carefully. First of all, I always _need_ to have my work
> "backed up". This means, it doesn't matter I am fixing the most
> important bug in the world, or I am doing something really really
> crazy that I will discard with 99.9% of probability, I want my work
> backed up. This means I want to push my work to the server frequently.
>
> So, when I start something crazy that will very probably be discarded,
> I'd like that thing to dissappear as it never existed, just because it
> was really crazy (note this is not always true, if I do something that
> I consider is really nice and fails for whatever reason, is important
> for the project too to know that it didn't succeed, and the reasons,
> so fails are important too).
>
> Possible options:
>
> - Use "implicit branching" and keep going.
> - Use specific "named branches" for that crazy work and perform
> "--close-branch" when you are finished.
> - Use patch queues.
> - Use repository cloning.
>
> = Implicit branching =
>
> While this feature is really cool, I have a problem here. Some, I'd
> say. I'd like my "branch" to have some kind of information about
> what's going on on that branch (Ok, you can tell, add "EXPERIMENTAL:
> testing whatever" to the first commit), but that isn't what I really
> want.
>
> Also, when I am working very intensively on a feature, my tip will
> point to the most experimental change, what I really don't want,
> because people that clone my repo will think my repo is unstable.
>
> Also, when asking someone else to pull from your repo so they can
> merge upstream (if you didn't merge), is pretty uncomfortable to say:
> "hey Nick plz pull from my repo revision 58e3a283".
>
> = Named branches =
>
> They pollute the repo for this purpose. They are not meant to do this
> work. They are cool for fixed stuff that will never change: this
> commit belongs to named branch "v2.0", and will always be that way.
> But this is not the solution I am looking for.
>
> For instance, take a look at http://hg.mozilla.org/mozilla-central/.
> That is exactly what I want to avoid by all means.
>
>
> = Patch queues =
>
> They are pretty cool, but if you are working alone. Using patch queues
> on real complex projects is a "no-go". You are working on "featureX"
> patch queue and in "bugfixY", and when you pop both, you update to
> upstream tip, push again, and "TaDa!" your patch featureX won't apply.
> And that is what you get: "I cannot apply featureX". Bye bye, baby.
>
> Of course this has a fix moving back to other revision... but this
> takes your time out. It isn't instant. You need to always pop & update
> & push, what is a really dangerous source of possible conflicts.
>
> = Repository cloning =
>
> This feels like the cleaner solution. You just do "hg clone myproject
> myproject-featureX" and work on your "myproject-featureX". The
> downside ? If you want to keep your advances backed up as I already
> said, you need to push your whole project again and again (once for
> each feature or bugfix that you want to separate from the main
> development repository).
>
> So, following this last solution I came up with an idea: what if
> Mercurial could generate this remote branches easily ? AFAIK Mercurial
> after cloning a local repo will improve disk usage by creating hard
> links.
>
> The idea I would like to develop (I may need some guidance, maybe
> asking on #mercurial IRC channel) is an extension that basically
> performs this actions:
>
> - hg remotebranch --create featureX
>
> This adds to your .hg/hgrc a new entry "featureX = ssh://......."
> being copied and modified from the default/default-push entries,
> previously found on this file.
>
> Also, sends the server a petition to perform a simple "hg clone
> project project-featureX" on the same directory as the previous
> project repository, acting as a new branch. You push to that by "hg
> push featureX" until you are done.
>
> - hg remotebranch --delete featureX
>
> This performs a petition to the server that asks it to delete the
> repository featureX. This will just drop the repository.
>
> We could add some kind of "security" check that won't allow you to
> delete the one on "default-push" (or "default" if this doesn't exist).
>
> = Conclusion =
>
> So the idea for this extension is to ask the server to clone/delete
> your project repository adding meaningful names to the clones, acting
> as if they were branches.
>
> This is good because of various reasons:
>
> - Fast. The server will perform the clone, and if done right, they are
> all hard links until something changes.
>
> - Optimizes out disk usage.
>
> - Allows you to branch-and-drop crazy ideas as if they never existed.
>
> - You have your data always backed up.
>
> Downsides:
>
> - You have to be careful because at the beginning you only have one
> repo pointing out to various places. This means that you could very
> easily mix up pushes and push to the branch "bugfix1234" the things
> you wrote for branch "featureX".
>
> =============
>
> So, ideas ? comments ? ways to improve the work model ? Whatever is
> welcome... ;)
>
>
> Best regards,
> Rafael Fernández López.
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at selenic.com
> http://selenic.com/mailman/listinfo/mercurial-devel
>

... but if you're disconnected you won't be able to create a remote
branch and that will be a big downer if you get used to doing things
this way. pbranch gets mentioned a lot here just for this, but i have
never used it.

another option is to have two clones. a pristine one, and an
experimental one. you can create all the named branches you like in
the experimental one, and only if a feature branch leads anywhere you
can pull that branch only into your pristine tree. you can also tell
your "users" to clone or pull a named branch from your experimental
repo.

-vk